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II. RELATED APPEALS AND INTERFERENCES 

There are no appeals or interferences known to appellants, the appellants' 
legal representative, or assignee which will directly affect or be directly affected by or 
have a bearing on the Board's decision in the pending appeal. 

III. STATUS OF CLAIMS 

Claims 22-25 are pending in the Application. Claims 22-25 stand rejected. 

IV. STATUS OF AMENDMENTS 

No amendments were made to the claims subsequent to the final rejection, 
having a mailing date of November 30, 2005. 

V. SUMMARY OF THE INVENTION 

The traditional approach to managing computer systems has been to design 
and deploy the management system based primarily on which particular type of 
hardware platform that the subject systems execute on. This is a purely technology 
based approach to systems management which does not align the management of the 
system to the business functionality of the system or the business requirements of the 
user of the system. [Page 2, lines 3-12.] 

Some companies derive a significant percentage of their revenues from 
strategic outsourcing services provided to other companies, such as banks and other 
financial institutions, which are largely dependent upon information technology to 
support their products and services to their customers. After such a bank contracts 
with the strategic outsourcing services of a service provider, it will then go in and hire 
most of the staff who had been previously running the information technology shop at 
the bank, and attempt to consolidate equipment and operations more efficiently. The 
advantage that the outsourcing company can bring to this situation is that it has 
invested considerable research and development into defining processes around these 
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type of IT disciplines, such as data storage and output management, system 
administration, event management, paging and escalation, security management, 
operations automation, change orders, etc. [Page 2, line 13 - page 3, line 7.] 

The problem with this process in general is that it has to be reinvented each 
time the outsourcing company goes into a new outsourcing arrangement with a new 
customer. There is some advantage that the outsourcing company can employ by 
having the same employees cover the information technology needs of a multiple of 
companies by sharing their time among those companies. However, the design of the 
outsourcing operation still is often done on an ad hoc basis, dependent upon the 
particular systems in place at the new customer. [Page 3, lines 1 1-22.] 

The present invention provides a way for an outsourcing company to leverage 
from the knowledge gained while performing such outsourcing services from one 
client to the next. [Page 4, lines 1-3.] 

Referring to FIGURE 2, a company will decide that they wish to no longer 
completely support their Information Technology (IT) environment with their own 
people, and will turn to an outsource service provider (e.g., IBM) to request that IBM 
(step 201) begin to provide two specific services for their environment: Problem 
Management (identifying and solving problems with the environment, discovering 
root cause, recommending changes, etc.) and Event Management (tied to Problem 
Management, but focused on immediate response, both automated and manual, to 
electronic events that are detected in the environment - e.g., a server goes down, 
creating an electronic event indicating that it can no longer be "seen" on the network). 
In order to provide these services, IBM will build a Delivery Framework 320 
describing what people, processes and tools (and identifying information 
requirements) that will be deployed to provide the desired functionality. [Page 31, 
lines 9-20.] 

The next step (step 202) identifies the specific Solution Scope 317 as 
described in the contract with the customer, and based on common practices for 
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delivering certain types of services. For Problem Management and Event 
Management, this entails identifying hours of service, and which components (in 
general terms, such as "all NT servers") which are in scope, etc. The next step 
(step 203) identifies the Specific Solution Requirements 314 for this solution. IBM 
may go out to the customer site and inventory every piece of equipment that is in the 
scope of the contract, including servers, workstations, network routers, hubs, etc. 
FIGURE 9 illustrates an example of such inventory for "in scope" hardware. 
[Page 32, lines 3-11.] 

At this point, each component is mapped (step 204) to the lowest level 
Architectural Building Block (ABB) 308 described in the ESD Technical Model 
(ESDTM) 301. FIGURE 10 illustrates an example of the lowest level ABBs 308 
available in the ESD Technical Model 301. FIGURE 1 1 illustrates an example of the 
mapping of each component in the inventory (FIGURE 9) to the ABBs (FIGURE 10). 
For example, there perhaps is a building block identified as "Workstation". Each 
workstation is identified as being an instance of that ABB 308. In addition to being 
an instance of ABBs 308, each inventoried component will also have certain 
attributes which will also be captured. Again using the workstation example, in the 
ABB definition for a "Workstation," it will be indicated that each workstation has 
attributes such as an Operating System, a CPU, a Disk Drive, a Network Card, etc. 
Each of these attributes will be captured. [Page 32, lines 12-23.] 

As well as categorizing each component in the customer environment and 
assigning/identifying attributes, the relationships (Design Object Relationships 312) 
between these components are identified (step 205). For example, a workstation is 
connected to a hub, which is one type of relationship. Another relationship is what 
application a workstation is implemented to support for a customer. FIGURE 12 
illustrates an example of such an identified Design Object Relationship 312 for the 
contract with the customer. [Page 33, lines 1-7.] 
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Once the entire customer environment in terms of ABBs have been described, 
then the systems management ABBs in the ESDTM are looked at that are required to 
provide the specific Problem and Event Management services. For example, it will 
be known that a component described by an ABB will be needed to provide the 
capability to store and forward events. FIGURE 13 illustrates an identification of 
which ABBs 308 from the Technical Model 301 are needed to deliver the "in scope" 
services of the customer. FIGURE 14 illustrates examples of ABB Lists and 
Relationships indicated in FIGURE 13. [Page 33, lines 8-15.] 

When all of the ABBs are identified that are needed to provide Problem and 
Event services, then all of the ABBs are mapped describing the customer 
environment, and all the systems management ABBs in the model together, based on 
the relationships of the customer ABBs and the relationships contained in the model. 
At this point, there is a consistent model for the entire systems management solution 
for Problem and Event Management for the customer, that is also consistent with the 
overall model (ESDTM) for delivering service. This complete model is made up of 
Design Objects 313 based on logical groupings of ABBs 308. FIGURE 15 illustrates 
identified Design Objects 3/3 for the "in scope" services based on logical groupings 
of ABBs 308 for the customer example. [Page 33, line 16 - page 34, line 2.] 

The consistency of the Technical Model 301 is ensured through maintaining 
the groupings of the ABBs 308 identified in the Logical Level 0 310 and 1 311 
Models. Those models 310, 311, the relationships 309 and the ABBs 308 are all 
designed based on a common set of Principles 307, identified to satisfy Key 
Requirements 306, derived from the ESD Technical Architecture Scope 305 and 
Objectives 304, which all are developed to drive toward the ESD Technical 
Architecture Vision 303. [Page 34, lines 3-9.] 

With the complete set of Design Objects 313 identified for the customer, 
specific Tool Selection Criteria 315 are defined (step 206). For example, from the 
Technical Model 301, it is known that all the systems management tools selected had 
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to be capable of working on all of the platforms (servers, workstations, etc.) that are 
in the customer environment. From the attributes identified in the Design 
Objects 313, it is known what that list of platforms is, so criteria are identified that 
state that the "tool for storing and forwarding events must execute on Windows 95, 
Window NT, and AIX Operating systems, etc." [Page 34, lines 10-17.] 

With the defined Tool Selection Criteria 315, all the specific tools (including 
hardware and software) are selected, and based on the Specific Solution 
Requirements 314, and Solution Scope 317, in step 207, a Detailed Technical 
Design 316 for the systems management environment is developed. FIGURE 16 
illustrates an example of such Tool Selection. In this example, a design object is 
identified that includes a mainframe, a data store, a hub and a management server. 
For each of these parts of the design object, it is known how they relate, or are 
combined to provide functionality. Based on the servers needed to be provided (in 
this example, problem management and event management) it is known what 
relationships between these components are required. These requirements are used to 
evaluate available tools to select tools that satisfy all the relational requirements 
contained in the design object. FIGURE 17 illustrates an example of a detailed 
Technical Design with Design Objects for the example. When it is known that all of 
the requirements have been satisfied dictated by the relationships described in the 
design objects by selecting all the appropriate tools (software and hardware), a 
consistent, low level design can be created of the ESM solution. By maintaining all 
relationships, integration is ensured into the overall systems management 
environment. This example illustrates components (such as Netview Server, Tivoli 
Enterprise Console, hubs, routers, etc.) that would be selected and deployed based on 
the method. [Page 34, line 18 - page 35, line 13.] 

By using this method, a specific Technical Framework 302 is designed for the 
customer that satisfies all of their requirements for Problem and Event Management. 
[Page 34, lines 14-15.] 
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VI. ISSUE 

Claims 22-25 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
Guheen etal (U.S. Patent No. 6,957,186). 

VII. ARGUMENT 

Claims 22-25 are not anticipated by Guheen. For a claim to be anticipated 
under 35 U.S.C. § 102, each and every element of the claim must be found within the 
cited prior art reference. 

A. General 

Guheen merely discloses displaying a graphical representation of existing 
network components. As will be further asserted below, Guheen merely is concerned 
with the existing components within a network or system, and is not in any way 
concerned with the creation of a technical framework for use in delivering a specific 
set of information technology services for a customer. 

The present invention as claimed, determines a solution scope for a technical 
framework to be created , maps existing equipment to architectural building blocks in 
a technical model, creates a list of design objects as a function of the solution scope 
for the technical framework, and then designates relationships between the design 
objects as a function of that solution scope and services to be provided to the 
customer. Guheen might be useable in a system as recited in the present application, 
but it would be merely used as a graphical or pictorial representation of existing 
equipment and components, which could then be potentially used by the system of the 
present invention to create a technical framework for use in delivering a specific set 
of information technology services for a customer. Thus, a deficiency in the 
teachings of Guheen is that it does not go to the next steps as recited in the claims. 
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B. First Claim Element 

i. Claim Language 

The claims specifically recite the determination of a solution scope for the 
technical framework to be created . The solution scope is further recited as being 
guided by an information technology services contract with the customer. Yet still 
further, the claims recite that the solution scope is based on common practices for 
delivering certain types of information technology services. 

ii. Cited Language in Guheen 

Step 31a in Guheen merely teaches creating a database that includes a listing 
of components within an existing network. The Abstract of Guheen merely describes 
how Guheen teaches the creation and display of a pictorial representation of an 
existing system having a plurality of components. It is further described how such a 
pictorial representation may display how such existing components have deliverable 
features for building, management, and support information. Column 2, lines 1-35 
cited by the rejection is the entirety of Guheen's Summary of the Invention, which 
merely reiterates what is briefly noted in the Abstract that components of an existing 
system are pictorially depicted on a display system to convey information regarding 
such existing components. Such pictorial depictions may describe how such existing 
components deliver services and how they are related to each other, and also may 
display information relating to the building, managing, and supporting of such 
existing system components. Column 9, lines 1-35 describes how a database may be 
created to list redundant or omitted components, which components may correspond 
to vendor services that are not available to provide such services, and may provide a 
listing of redundant vendor services. Again, these listings are all related to merely 
displaying information about existing system components. Column 10, lines 1-35 
describes how the pictorial representation may depict priorities between components, 
and how certain components may be dependent upon other components. Column 30, 
lines 1-25 describes the depiction of the organization of management teams for 
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handling certain areas within a development environment. This language also 
describes an introduction of a new business capability and how it fits within the 
environment. Thus, Figure 53 described in the cited language of Guheen is for 
depicting the characteristics of the people within the management organization so that 
the right choices for tools and training can be made for the set of management teams. 
Claim 1 in Guheen recites a method for visualizing various components of a web 
architecture framework using a display device to facilitate assessment of the 
components of a system. Displayed are such items as features of products or services, 
components within a framework, coverage provided by products or services, strengths 
of products or services, and weaknesses of products or services. 

iii. Claim Elements Not Anticipated 

There is nothing described in these cited passages (see section B.ii. above) 
about creating a solution scope for the technical framework for use in delivering a 
specific set of information technology services for a customer. Further, there is 
nothing in this language describing or suggesting that the solution scope is guided by 
an information technologies services contract with the customer. Moreover, the 
language in the claims reciting that the solution scope is based on common practices 
for delivering certain types of information technology services has not in any way 
been specifically addressed in the rejection. These portions of Guheen do not in any 
way teach or suggest such language within the claims. 

Furthermore, the rejection does not explain with any specificity how the cited 
language in Guheen teaches the limitations recited in the claims. There is not even a 
matching up of terms in the claims to terms in Guheen. For this reason alone, the 
rejection fails to put forth a prima facie case of anticipation. 



9 



AUS9-2001-0209-US1 



PATENT 



C. Second Claim Element 

i. Claim Language 

The next step in the claims recites the mapping of customer's existing 
equipment to lowest level abstractions of architectural building blocks in a technical 
model, wherein the technical model describes people, processes, tools and 
information used to deliver specific services to customers. The architectural building 
blocks comprise architectural components that are sufficiently modular and bounded 
to be described as self-contained entities. 

ii. Cited Language in Guheen 

In rejecting these claim limitations, the rejection refers to elements 31b and 
31c in Figure 3 of Guheen. Step 31b teaches creating a second database, which 
includes a listing of all services provided by vendors that correspond to the 
components of that area of the framework. Step 31c is comparing the listing of the 
components with the listing of the vendor services corresponding to those 
components. Thus, step 31c compares the database created in step 31a to the 
database created in step 31b. This is a comparison of the components of an existing 
network framework to a list of services provided by vendors that correspond to such 
components. 

Column 2, lines 1-35 cited by the rejection is the entirety of Guheen's 
Summary of the Invention, which merely reiterates what is briefly noted in the 
Abstract that components of an existing system are pictorially depicted on a display 
system to convey information regarding such existing components. Such pictorial 
depictions may describe how such existing components deliver services and how they 
are related to each other, and also may display information relating to the building, 
managing, and supporting of such existing system components. Column 9, lines 1-35 
describes how a database may be created to list redundant or omitted components, 
and which components may correspond to vendor services that are not available to 
provide such services, and may provide a listing of redundant vendor services. Again, 
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these listings are all related to merely displaying information about existing system 
components. Column 30, lines 1-25 describes the depiction of the organization of 
management teams for handling certain areas within a development environment. 
This language also describes an introduction of a new business capability and how it 
fits within the environment. Thus, Figure 53 described in the cited language of 
Guheen is for depicting the characteristics of the people within the management 
organization so that the right choices for tools and training can be made for the set of 
management teams. Column 56, lines 10-67 merely describes in an abstract manner 
how to go about a design processes, how the quality of design process affects the 
magnitude of the efforts required, how parts of a design process may occur after a 
system test starts, how to sequence tasks, and how usability can be used in a system 
design. Claim 1 in Guheen recites a method for visualizing various components of a 
web architecture framework using a display device to facilitate assessment of the 
components of a system. Displayed are such items as features of products or services, 
components within a framework, coverage provided by products or services, strengths 
of products or services, and weaknesses of products or services. 

iii. Claim Elements Not Anticipated 

Contrary to the rejection, there is no reference in the steps 31b and 31c to 
lowest level abstractions of architectural building blocks in a technical model, 
wherein the technical model describes people, processes, tools and information used 
to deliver specific services to a customer. Furthermore, the other language cited 
above in section C.ii. does not teach the technical model describing people, processes, 
tools and information used to deliver specific services to customers. Nor does it teach 
architectural building blocks comprising architectural components that are 
sufficiently modular and bounded to be described as self-contained entities. 

Further, the rejection does not explain with any specificity how the cited 
language in Guheen teaches the limitations recited in the claims. There is not even a 
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matching up of terms in the claims to terms in Guheen. For this reason alone, the 
rejection fails to put forth a prima facie case of anticipation. 

D. Third Claim Element 

i. Claim Language 

The next limitation within the claims creates a list of design objects as a 
function of the solution scope for the technical framework, wherein the design objects 
are based on logical groupings of architectural building blocks, including software 
and hardware components. 

ii. Cited Language in Guheen 

The rejection has cited steps 3 Id and 31e in Figure 3 of Guheen. Step 3 Id 
creates of list of components not being provided by a vendor service whereas step 31e 
creates a list of components being provided by more than one vendor services. 
Column 14, lines 40-67 describes Figures 34-50 of Guheen. Figure 34 is described as 
an exemplary data page providing more detail for selected components of the web 
architecture framework. What may be further illustrated are more details about each 
of these components and whether certain services provide operations associated with 
a component. Figures 35-50 illustrate exemplary architectures of various components 
of the systems of business 1, business 1 offering a variety of products in the 
hardware, networking, architecture, infrastructure, security and development tool 
areas for building applications and systems. Column 23, lines 25-67 describes object 
oriented programming in general. Column 30, lines 1-25 of Guheen is described 
above in section C.ii. Column 38, lines 10-30 describes information 
management 202. This language describes that services provided by such an 
information management team may be done in accordance with a service level 
agreement that defines how quickly a new data element is created and how repository 
changes are communicated, and more generally defines the division of 
responsibilities between the information management team and the other project 
teams at a detailed level. 
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iii. Claim Elements Not Anticipated 

Steps 3 1 d and 3 1 e have nothing to do with creating a list of design objects as a 
function of the solution scope for the technical framework wherein the design objects 
are based on logical groupings of architectural building blocks. Further, none of the 
other cited language (see section D.ii.) provides any description of a list of design 
objects created as a function of the solution scope for the technical framework, 
wherein the design objects are based on logical groupings of architectural building 
blocks. 

Furthermore, the rejection does not explain with any specificity how the cited 
language in Guheen teaches the limitations recited in the claims. There is not even a 
matching up of terms in the claims to terms in Guheen. For this reason alone, the 
rejection fails to put forth a prima facie case of anticipation. 

E. Fourth Claim Element 

i. Claim Language 

The next element in the claims recites the designations of relationships 
between the design objects as a function of the solution scope and the specific set of 
information technology services for the customer. 

ii. Cited Language in Guheen 

The rejection has cited Figure 4 of Guheen. Figure 4 is merely concerned 
with displaying a pictorial representation of a system and its components, along with . 
indicia coding the components of the system in order to indicate required components 
for the implementation of the system. 

Column 13, lines 1-45 of Guheen describes the depiction of alliances between 
business entities, the comparison of databases for services of vendors, and further 
describes operation 26 described in Figure 1 , which is indicia coding of components 
of the system in order to convey information pertaining to which components of a 
system products or services relate. Column 30, lines 40-67 describes statements 
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defining roles of positions in a development organization and list management teams 
within an IDEA model that supports the efforts of a system building team. 
Column 50, lines 1-30 describes service level agreements between the environment 
management team and developers, which set forth how technical support is to be 
provided. 

iii. Claim Elements Not Anticipated 

The display of components of a system including indicating what components 
are required (as taught by Figure 4 in Guheeri) is not the same as designating 
relationships between design objects as a function of the solution scope in the specific 
set of information technology services for the customer, wherein the design objects 
are a function of the solution scope for the technical framework and are based on 
logical groupings of architectural building blocks, including software and hardware 
components, wherein the solution scope is guided by an information technology 
services contract with the customer and is based on common practices for delivering 
certain types of information technology services. 

None of the other cited language (see section E.ii.) is describing designating 
relationships between design objects as a function of the solution scope and the 
specific set of information technology services for the customer. 

Further, the rejection does not explain with any specificity how the cited 
language in Guheen teaches the limitations recited in the claims. There is not even a 
matching up of terms in the claims to terms in Guheen. For this reason alone, the 
rejection fails to put forth a prima facie case of anticipation. 

F. Claim 23 

Claim 23 recites an additional element as follows: 

a detailed technical design developed for the 
information technology services for the customer based 
on tool selection criteria that are dependent upon the list 
of design objects and the designated relationships 
between the design objects. 
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The rejection does not in any way address this claim language. Therefore, the 
rejection fails to prove a prima facie case of anticipation in rejecting claim 23. 

G. Conclusion 

For the foregoing reasons the claims are allowable over the prior art. 

Respectfully submitted, 

WINSTEAD SECHREST & MINICK P.C. 



Attorneys for Appellants 




P.O. Box 50784 
Dallas, Texas 75201 
(512)370-2851 
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IN THE CLAIMS 

1 22. A method for creating a technical framework for use in delivering a specific 

2 set of information technology services for a customer, comprising the steps of: 

3 determining a solution scope for the technical framework to be created, the 

4 solution scope guided by an information technology services contract with the 

5 customer, the solution scope based on common practices for delivering certain types 

6 of information technology services; 

7 mapping the customer's existing equipment to lowest level abstractions of 

8 architectural building blocks in a technical model, the technical model describing 

9 people, processes, tools and information used to deliver specific services to 

10 customers, the architectural building blocks comprising architectural components that 

1 1 are sufficiently modular and bounded to be described as self-contained entities; 

12 creating a list of design objects as a function of the solution scope for the 

13 technical framework, the design objects based on logical groupings of architectural 

14 building blocks, including software and hardware components; and 

15 designating relationships between the design objects as a function of the 

16 solution scope and the specific set of information technology services for the 

17 customer. 



1 23. A technical framework for use in delivering a specific set of information 

2 technology services for a customer, comprising the steps of: 

3 a solution scope determined for the technical framework to be created, the 

4 solution scope guided by an information technology services contract with the 

5 customer, the solution scope based on common practices for delivering certain types 

6 of information technology services; 

7 a mapping of the customer's existing equipment to lowest level abstractions of 

8 architectural building blocks in a technical model, the technical model describing 
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9 people, processes, tools and information used to deliver specific services to 

10 customers, and the architectural building blocks comprising architectural components 

1 1 that are sufficiently modular and bounded to be described as self-contained entities; 

12 a list of design objects created as a function of the solution scope for the 

13 technical framework, the design objects based on logical groupings of architectural 

14 building blocks, including software and hardware components; 

15 designated relationships between the design objects as a function of the 

16 solution scope and the specific set of information technology services for the 

17 customer; and 

1 8 a detailed technical design developed for the information technology services 

19 for the customer based on tool selection criteria that are dependent upon the list of 

20 design objects and the designated relationships between the design objects. 

1 24. A computer program product for storage on a computer readable medium and 

2 operable for creating a technical framework for use and delivering a specific set of 

3 information technology services for a customer, comprising the program steps of: 

4 determining a solution scope for the technical framework to be created, the 

5 solution scope guided by an information technology services contract with the 

6 customer, the solution scope based on common practices for delivering certain types 

7 of information technology services; 

8 mapping the customer's existing equipment to lowest level abstractions of 

9 architectural building blocks in a technical model, the technical model describing 

10 people, processes, tools and information used to deliver specific services to 

1 1 customers, and the architectural building blocks comprising architectural components 

12 that are sufficiently modular and bounded to be described as self-contained entities; 

13 creating a list of design objects as a function of the solution scope for the 

14 technical framework, the design objects based on logical groupings of architectural 

1 5 building blocks, including software and hardware components; and 
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16 designating relationships between the design objects as a function of the 

17 solution scope and the specific set of information technology services for the 

1 8 customer. 



1 25. A data processing system operable for creating a technical framework for use 

2 in delivering a specific set of information technology services for a customer, 

3 comprising: 

4 a processor; 

5 an input device; 

6 an output device; 

7 a memory unit; and 

8 a bus system for coupling the processor to the input device, output device, and 

9 memory unit, the processor further comprising: 

10 circuitry for determining a solution scope for the technical framework to be 

11 created, the solution scope guided by an information technology services contract 

12 with the customer, the solution scope based on common practices for delivering 

1 3 certain types of information technology services; 

14 circuitry for mapping the customer's existing equipment to lowest level 

15 abstractions of architectural building blocks in a technical model, the technical model 

16 describing people, processes, tools and information used to deliver specific services 

17 to customers, and the architectural building blocks comprising architectural 

18 components that are sufficiently modular and bounded to be described as self- 

1 9 contained entities; 

20 circuitry for creating a list of design objects as a function of the solution scope 

21 for the technical framework, the design objects based on logical groupings of 

22 architectural building blocks, including software and hardware components; and 

23 circuitry for designating relationships between the design objects as a function 

24 of the solution scope and the specific set of information technology services for the 

25 customer. 
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EVIDENCE APPENDIX 

No evidence was submitted pursuant to §§1.130, 1.131, or 1.132 of 37 C.F.R. 
or of any other evidence entered by the Examiner and relied upon by Appellant in the 
Appeal. 
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RELATED PROCEEDINGS APPENDIX 

There are no related proceedings to the current proceeding. 
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